1. Field of the Invention
The invention relates to the Network Applications Platform (NAP) particularly with respect to the prompt management system therefor.
2. Description of the Prior Art
The NAP is described in U.S. Pat. No. 5,133,004, issued Jul. 21, 1992, and is assigned to the assignee of the present invention. The NAP contains telephone network functionality actuatable by commands from supported Network Applications, such commands controlling answering a telephone call, initiating a telephone call, and playing a voice message over an established telephone connection. Voice messages are identified by a NAP Message ID and are stored in a NAP Voice File accessed through a NAP Voice Input/Output Data Base (VIODB) containing the NAP Message IDs. The Network Application can command the NAP to receive, and store in the Voice File, a voice message from an established telephone connection. NAP assigns a Message ID to the message and returns the Message ID to the application. The commands to which NAP is responsive are denoted as Application Interface Module (AIM) commands and all of the described NAP structure and functionality is explained in detail in said Patent No. 5,133,004. Said Patent No. 5,133,004 is incorporated herein by reference in its entirety.
The NAP is provided with a prompt management system denoted as Voice Utility/Prompt Expansion Processor (VU/PEP). VU/PEP is described in the following VU/PEP documentation: A Series Network Applications Platform (NAP), System Administration Guide (4178 1279-000), December 1993; and A Series Network Applications Platform (NAP), Programming Reference Manual (4178 1287-000), Dec. 1993. Said VU/PEP documentation is incorporated herein by reference to detail the state of the art.
Although one VU can be used by all Network Applications, each Network Application must have one or more copies of its own PEP. A user creates or modifies the prompts to be spoken by the user's Network Application by interactively utilizing VU and NAP to generate a VU application that defines the prompt elements. A prompt is composed of and defined by a sequence of static and dynamic elements. A static element denotes a fixed phrase, whereas a dynamic element provides a location in the prompt for variable data to be provided by the Network Application at run time. For example, in the prompt "you have &lt;number&gt; new messages", the phrases "you have" and "new messages" are static elements whereas &lt;number&gt; is a dynamic element to be provided by the Network Application in accordance with the conditions at run time. The voice for the static elements may be recorded by the user over a telephone connection to NAP under control of the VU application. The voice for the static elements are recorded in the NAP Voice File identified by NAP Message IDs as explained in said Patent No. 5,133,004. The NAP Message IDs are returned by NAP to the VU application for storage in records in the VU database to be referenced when playing the prompts.
The dynamic data is managed pursuant to a fixed list of dynamic element types known as cardinal number, date/time, digit string, phone number, text identifier and NAP Message ID. The PEP contains arrays for expanding these dynamic data types over the range of dynamic data required. For example, the cardinal number array may contain elements for the numbers 0 through 99. The voice for the dynamic elements is recorded and stored, as discussed above, and the associated NAP Message IDs are appropriately stored in the arrays.
The user defines the prompts for the user's Network Application as ordered sequences of specific static elements and dynamic element types. These prompt definitions are interactively generated by the user utilizing VU and are stored in records in the VU database. These records are used by PEP to expand prompts for a given Network Application. These records may be cached in arrays first in order to improve performance. A Network Application invokes the playing of a prompt by issuing a Send Prompt (SP) or Enhanced Send Prompt (ESP) command to PEP naming the prompt and supplying the specific dynamic data appropriate to the run time conditions. The PEP expands the command into the sequence of NAP Message IDs appropriate to play the prompt. The Message IDs are loaded into a NAP Send Voice Message command for this purpose.
The SP and ESP commands are structured so that the dynamic data is always supplied in the command in the order it is to be used and is always used by PEP in the order it is supplied. Each supported dynamic element type is expanded according to a predetermined algorithm in PEP. For example, the prompt command might have date/time dynamic data arranged as MMDDYY. The data in this field is spoken in the order determined by the algorithm, such as day of the week, month, and day (e.g., "Thursday, May 19th"). The PEP is of fixed design so as to always expand the prompts in such a fixed manner. The design of VU/PEP is arranged for the playing of American English prompts. Accordingly, the Network Applications for NAP are written with the expectation that its prompts would be played in American English.
Although functioning well for the purposes intended, VU/PEP suffers from a number of disadvantages. A Network Application can only play its prompts in American English. If it is desired that a Network Application would play the same prompts in a second language, substantial reprogramming of the Network Application would be required. The prompts and elements for the second language would have to be added to the original set in order to create the required components in the second language. These new components would require unique identifiers. The Network Application would have to detect which language to play and use the appropriate prompt name in the Send Prompt Command. Additionally, the Network Application may be required to order different dynamic data in accordance with the language to be spoken. In other words, the Network Application itself would require an English version and another version for the second language. Because of syntactical and grammatical differences between languages, significant programming changes might also be required in the Network Application and PEP for supporting the second language. The problem may be further complicated if the second language utilizes adjectives that are gender sensitive. For example, Spanish requires gender agreement between adjectives and nouns. Thus, while English can say "one woman" or "one man", Spanish requires the "one" to be spoken differently based on the gender of the associated noun.
Similar problems are encountered because of the inflexibility of VU/PEP if, for example, it is desired to play time in the 24 hour military format as compared to the AM/PM 12 hour format of American English. Language differences in the playing of date and time may also result in similar difficulties. For example, in American English the date is played in month, day order, whereas in European languages date is spoken in day, month order.
In the VU/PEP that supports only American English, tables are utilized to store the prompt definitions with the elements thereof always in the same order. The expansion of dynamic data is always handled the same way by dynamic data processing code embedded in PEP. Because of this, it is appreciated that in order to provide a multi-lingual prompt capability utilizing VU/PEP, alterations of the functional code, call flow and programmatic logic of the Network Application as well as the PEP code are required for each language.
As discussed above, VU/PEP utilizes an embedded dynamic data processor for the expansion of dynamic data for a limited set of dynamic data types. Modifications to the Network Application and PEP would be required to play prompts utilizing a different dynamic element type. In addition, the format of the SP and/or ESP commands would have to be enhanced to provide for the new type of dynamic data. For example, if it were desired to play prompts with monetary values, a change to the SP or ESP command would be required to support the new type of dynamic data. In addition, alterations to the dynamic data processor embedded in PEP would also be required to support the new dynamic element type. Not only would this arrangement require alteration of the Network Application and PEP code, but it would also be extremely limited in flexibility. Additionally, a multi-lingual capability with respect to the special dynamic element types would further exacerbate the difficulties.